Current cellular communication systems according to 3GPP specifications are typically based on the Evolved Packet System (EPS) which provides a new radio interface and new core network functions for broadband wireless data access. The EPS radio interface consists of a packet-switched network access via E-UTRAN (which is provided in addition to the 2G/3G network accesses via UTRAN and GERAN. The EPS core network functions include the Mobility Management Entity (MME), the Packet Data Network Gateway (PDN-GW) and the Serving Gateway (S-GW).
FIG. 1 shows a schematic diagram illustrating the general EPS architecture according to 3GPP TS 23.401, which represents a first example of a communication system architecture.
The UE representing a subscriber can be camped on, and thus served by, any one of different network accesses, namely the E-UTRAN or the UTRAN or the GERAN, but not two network accesses simultaneously. That is, when the UE is camped on E-UTRAN, it is not reachable over UTRAN or GERAN. The MME is responsible for mobility management procedures in EPS. Specifically, it is responsible for knowing the subscriber's location in the E-UTRAN, it authenticates the subscriber, and it supervises the resources granted for subscribers via controlling the PDN-GW and the S-GW.
In case specific services could not be provided to a subscriber in the EPS by way of its packet-switched network access, i.e. via the E-UTRAN, there is specified Circuit-Switched Fallback (CSFB). Such Circuit-Switched Fallback is for example useful for the initial phase of EPS deployments (when EPS access is available in limited areas only) so to make usual services like call, SMS, USSD and locationing available for UEs that are camped on E-UTRAN.
FIG. 2 shows a schematic diagram illustrating the EPS architecture for CS fallback and SMS over SGs according to 3GPP TS 23.272, which represents a second example of a communication system architecture.
The EPS architecture for CS fallback and SMS defines the SGs interface between MME and MSC Server/VLR (which could also be referred to as a mobile switching system MSS). When a UE registers in the EPS, it can indicate its CSFB capability in the request. If the EPS supports CSFB, the MME performs a location update on the SGs interface on behalf of the UE to an MSC Server/VLR. In turn, the MSC Server/VLR downloads CS subscription data from the HLR with a normal location update procedure. So, the UE will be registered into the MSC Server/VLR. Then, mobile-terminated (MT) CS events of the UE (e.g. call, SMS, Mobile-Terminated location request, USSD) will be routed to the MSC Server/VLR. When the MT CS event arrives at the MSC Server/VLR, the MSC Server/VLR sends a paging request to the MME over the SGs interface to indicate the incoming MT CS event and to search the UE. For call, USSD and location request procedures, the UE is then forced back to a CS network (i.e. UTRAN/GERAN) with a CSFB mechanism. When the UE is camped on the CS network, the actual MT CS procedure (e.g. call, SMS, location request, USSD) is executed by the MSC Server/VLR as if the UE was originally served in the CS domain. When the MT CS procedure is completed, i.e. the service is executed, the UE returns to the EPS, namely the E-UTRAN.
In an effort to ensure consistent service experience for subscribers, the IMS Centralized Service (ICS) concept is specified, which is applicable in the EPS framework. By the ICS concept, the services are provided centrally from the centralized IMS service domain, instead of being provided locally from a specific access domain. The centralized IMS service domain is access agnostic.
FIG. 3 shows a schematic diagram illustrating the ICS architecture according to 3GPP TS 23.292, which represents a centralized service architecture.
In the ICS architecture (also referred to as IMS service continuation and continuity reference architecture), the circuit-switched domain (including GERAN/UTRAN, MSC Server, etc.) becomes a simple CS access network which does not execute services itself, but only ensures that the UE sessions are delivered to the centralized IMS service domain where the services are actually executed. When an UE using ICS roams between the different access networks (like E-UTRAN and CS), the UE can use the same services independently from its currently used access because those are executed in the centralized IMS service domain.
When the UE is under CS access and performs a usual location update procedure to the MSC Server, the MSC Server registers itself in the IMS service domain, namely in the Service Centralization and Continuity Application Server (SCC-AS) therein, as a contact point for the UE for the provision/execution of centralized services. So, when a mobile-terminating session arrives at the SCC-AS for this UE, the SCC-AS will know to which MSC Server the session should be routed in order to reach the UE so as to provide/execute the service.
Accordingly, the service provision/execution for a UE in such centralized service network system, like the ICS service domain, is based on the registration of a mobile switching system as a contact point for centralized services for the UE. In order to ensure service continuity in such centralized service network system, like the ICS service domain, it is thus required to ensure a correct and continuous registration of the contact point for centralized services for the UE.
Such correct and continuous registration could however not be ensured with conventional procedures when the UE exercises mobility between different mobile switching centers, i.e. cells belonging to different mobile switching centers.
This will become evident from the following description of re-routing procedures in two exemplary scenarios of CSFB in the ICS architecture. In both exemplary scenarios, it is assumed that the UE is registered to ICS MSS_1 over the SGs interface, and ICS MSS_1 is registered for the UE as contact point for ICS in the S-CSCF and the SCC-AS. Further, it is assumed that the UE is to be re-routed from ICS MSS_1 (serving an E-UTRAN cell representing a source cell) to ICS MSS_2 (serving a GERAN/UTRAN cell representing a target cell) due to a CSFB mechanism.
FIG. 4 shows a signaling diagram of a conventional procedure in a first exemplary re-routing scenario, in which a deregistration request from ICS MSS_1 is issued before a registration request from ICS MSS_2 (as a result of the fact that MAP Cancel Location is issued by the HLR prior to MAP Update Location Response).
Initially, a MT call arrives at the SCC-AS, and the T-ADS functionality selects the CS domain. Accordingly, the call is routed to ICS_MSS_1 with using the specific contact information. To this end, the ICS MSS_1 starts paging the UE over the SGs interface. The UE performs CS fallback to a cell controlled by the ICS MSS_2, and starts a location updating procedure. In this context, the ICS MSS_2 may (optionally) send a MAP Send Identification to the ICS MSS_1, if a location update request was received with TMSI and ICS MSS_2 is configured properly. When a MAP Cancel Location is received from the HLR, the ICS MSS_1 sends a deregistration request to the S-CSCF to deregister itself from the S-CSCF and the SCC-AS. Hence, the S-CSCF releases the ongoing sessions of the UE (this call as well), and deregisters the UE from itself and the SCC-AS. When a MAP Update Location Response is received from the HLR, the ICS MSS_2 sends a registration request to the S-CSCF to registers itself to the S-CSCF and the SCC-AS. However, the call fails, as it has already been released (i.e. deregistration at the S-CSCF and the SCC-AS has already happened). Accordingly, the call fails in this re-routing situation, and thus there arises a problem in terms of service continuity.
FIG. 5 shows a signaling diagram of a conventional procedure in a second exemplary re-routing scenario, in which a deregistration request from ICS MSS_1 is issued after a registration request from ICS MSS_2 (as a result of the fact that, while MAP Cancel Location is issued by the HLR prior to MAP Update Location Response, a delay timer is used at the ICS MSS_1).
The initial procedure up to the update location procedure is the same as in the procedure of FIG. 4. When a MAP Cancel Location is received from the HLR, the ICS MSS_1 starts a delay timer to delay issuance of the deregistration request. When a MAP Update Location Response is received from the HLR, the ICS MSS_2 sends a registration request to the S-CSCF to registers itself to the S-CSCF and the SCC-AS. According to the current 3GPP specifications, if the S-CSCF receives such registration request, it shall release the ongoing sessions of the UE sessions (this call as well), thus deregistering the UE from itself and the SCC-AS, so the call will be released. After expiry of the delay timer, the ICS MSS_1 sends the deregistration request to the S-CSCF to de-register itself from the S-CSCF and the SCC-AS. As deregistration of the UE has already been performed, the S-CSCF ignores this deregistration request. Hence, the call fails, as it has already been released (i.e. deregistration at the S-CSCF and the SCC-AS has happened). Accordingly, the call fails in this re-routing situation, and thus there arises a problem in terms of service continuity.
In view of the above relating to cases of CSFB in the ICS architecture, if the UE is camped on E-UTRAN and is registered over the SGs interface to a first ICS MSS (i.e. is prepared for CS Fallback), it is considered as “CS Access”, i.e. the first ICS MSS can perform registration to SCC-AS as contact point for the UE, because when a mobile-terminating session is delivered to the MSC Server, the UE will execute CS Fallback to GERAN/UTRAN. Hence, the call will fail due to the fact that the registration at the SCC-AS cannot be ensured to be correct in a continuous manner during such re-routing situation (taking into consideration the 3GPP-specified rules for the behavior of S-CSCF and SCC-AS, i.e. S-CSCF has to release the call when a deregistration or registration request arrives).
More generally, corresponding problems could arise even without applying CSFB in the ICS architecture. For examples, if the UE is camped on GERAN/UTRAN and is registered to a first ICS MSS (e.g. over the A/lu/Gs interface) in the ICS architecture, it can move from its originally registered first ICS MSS to a new second ICS MSS while a call is being routed to it from the SCC-AS. In this case, the call will fail due to the fact that the registration at the SCC-AS cannot be ensured to be correct in a continuous manner during such re-routing situation (taking into consideration the 3GPP-specified rules for the behavior of S-CSCF and SCC-AS, i.e. S-CSCF has to release the call when a deregistration or registration request arrives).
Accordingly, there is a demand for enabling/realizing service continuity in a centralized service network system, especially in a situation of terminal mobility between different switching entities.